COMMENT ⊗   VALID 00004 PAGES
C REC  PAGE   DESCRIPTION
C00001 00001
C00002 00002	Dialnet memo #3
C00004 00003				  INITIAL CONNECTION PROTOCOL
C00009 00004				    TERMINATING A CONNECTION
C00011 ENDMK
C⊗;
Dialnet memo #3
SAILON by

















			       Dialnet Protocols

			  (or, the Protocols of DIAL)

			  Initial Connection Protocol

				  Mark Crispin

				     4/2/77

























     These protocols are being developed as  part of the Dialnet project at  the
Stanford University Artificial  Intelligence Laboratory supported  by NSF  grant
MCS 77-02080  with John  McCarthy  as Principal  Investigator.  The  project  is
described  in   a   paper   available   online  at   ARPAnet   host   SU-AI   as
DIALNE.MEM[DLN,MRC] (Dialnet Memo #1).

     This is ICP.PRO[DLN,MRC] at ARPAnet host SU-AI (octal 13, decimal 11.).
			  INITIAL CONNECTION PROTOCOL

     This is  the  basic mechanism  in  establishing a  connection  between  two
tertiary processes in a duplex connection.  In the discussion below, U refers to
the process which initially provokes the connection or USER, S refers to the the
process passively waiting for a connection or SERVER.

     Channel 0 is to  be used for  ICP, as it is  the official control  channel.
The other channels  are for auxillary  data purposes.  They  are connected in  a
similar way to  the initial connection  protocol; however process  ID's are  not
used for data channels.

     Following the establishment of a dialup connection, U should send an RST to
S, repeating if necessary  (see the Host-Host protocol  document) until the  RST
has been acknowledged.   Note that  according to the  Host-Host protocol,  RST's
must be  packet number  000 and  be acknowledged  with a  NOP that  acknowledges
packet 000 explicitly.  Of course, this  NOP always has packet number 001  since
RST initializes the packet sequence number mechanism.

     After this, a  DCP to  DCP connection has  been established  and a  process
connection may be  made.  There  is no official  time out  for a DCP  to DCP  or
process connection.  The decision on  whether or not to time  out is left up  to
each individual host, as is how long  is "reasonable" to wait.  It is  suggested
that the time out time be at least 15. seconds, and preferably longer.

     U must know the  process ID of  the S it  wants to connect  to.  As far  as
Dialnet is  concerned,  process  ID's are  arbitrary  ASCII  strings.   However,
conventions have been established as noted elsewhere.

     U instructs its DCP  to send an RPC  with the process ID  at S it wants  to
connect to.  The DCP at S's host passes the request along to S.  S may have been
waiting for a connection, or perhaps was created  by the DCP as a result of  the
RPC.  If no such process exists or the DCP is unable to create the process,  the
DCP should refuse the connection by sending back a CLS.

     S then decides whether or not it wants to talk to U.  If not, it  instructs
the DCP  to refuse  the connection.   Otherwise, it  accepts the  connection  by
instructing its DCP to send an RPC back to U's DCP, with a null process ID.  The
connection has now been established, and the process ID is no longer used by the
host-host protocol.  The two processes may now communicate with each other using
the host-host protocol including the MSG op-code.

     Auxillary channels are connected simply by sending an RPC on that  channel,
with a reply or either RPC to accept or CLS to refuse the attempt.  A process ID
is not necessary since there is already a process on this dialup connection.
			    TERMINATING A CONNECTION

     When a host wishes to terminate a  connection, it sends a CLS.  Once a  CLS
has been sent, no further MSG's may be sent and any MSG sent is to be replied to
with an ERR.  Of course, a new connection may be established with RPC.

     When a connection is terminated, the recepient  of the CLS must send a  CLS
to confirm terminating  the process.   This avoids timing  errors and  confusion
that could occur if both ends want to close at about the same time and both send
almost simultaneous CLS's.  The result is that if the receiver had sent a CLS, a
CLS coming  in will  be  seen as  a confirmation  even  if it  was  spontaneous.
Breaking the phone connection implies a  RST which in turn implies breaking  the
process connection.